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обеспечения системы компьютерного 
моделирования задач хаотической динамики 


В настоящее время распределённая разработка программного обеспечения приобретает всё большее 
значение. Это в первую очередь связано с ростом сложности создаваемых программных систем, 
повышением требований к функциональности и качеству конечного программного продукта, сложностью 
предметной области. Такие характеристики присущи системам компьютерного моделирования задач 
хаотической динамики. В связи с этим представляется актуальной распределённая разработка системы 
компьютерного моделирования и анализа решений задач хаотической динамики. В данной статье 
обосновывается выбор методологии распределённой разработки выптеозначенной системы. 


Целью статьи является разработка системы визуализации движения твёрдого 
тела и исследования характера его движения. Кроме того, система должна решать 
задачи исследования систем дифференциальных уравнений методами, аналогичными 
методам исследования движения твердого тела, интерактивного и пакетного расчёта 
решений поставленной задачи и её характеристик, ведения пополняемой базы 
данных решений задач, расширения системы посредством системы подключаемых 
модулей — плагинов. 

Исходя из собранных требований, были определены области изменчивости и 
расширения приложения. В качестве базовой была выбрана открытая компонентно- 
ориентированная архитектура, расширяемая посредством динамически подключаемых 
библиотек. Географическая разрозненность разработчиков определила дополнительное 
условие распределённости разработки, поставив тем самым задачу выбора методо- 
логии разработки. 

Для организации процесса разработки были рассмотрены два класса методо- 
логий: формальные и гибкие. Учитывая высокую вариативность и расширяемость 
системы, а также недостаточную определённость требований к отдельным из её 
подсистем, были выбраны гибкие методологии разработки. 

Гибкие методологии акцентируют внимание на предпочтении быстрой реакции 
на изменения требований следованию плану, планированию коротких этапов (1-2 ме- 
сяца) и итераций (1-2 недели), тесном сотрудничестве заказчиков и разработчиков, 
предпочтению функционирующего (пусть даже в ограниченном объёме) програм- 
много обеспечения подробным спецификациям. К таким методологиям в первую 
очередь относятся ЗСКОИМ и экстремальное программирование. 

Методология ЭСКОМ на сегодняшний день является одной из самых 
популярных методологий разработки. Она вводит в процесс разработки три роли: 
зсгит тазег, ргодас{ оуупег, {еат. Зсгит тазег является связующим звеном между 
менеджментом и командой. Как правило, эту роль в проекте играет менеджер 
проекта или {еат-[еа4. К основным его обязанностям относят: создание атмосферы 
доверия, устранение препятствий, оповещение команды 0б открытых вопросах и 
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проблемах, контроль за соблюдением практик и процесса в команде. Ргодис{ о\тег — 
это человек, отвечающий за разработку продукта. Он является единой точкой при- 
нятия окончательных решений для команды в проекте, именно поэтому это всегда 
один человек, а не группа или комитет. В его обязанности входит: формирование 
видения проекта, формирование рго4дисё БасК1о?, расстановка приоритетов задач, 
предоставление требований, понятных команде, взаимодействие с командой и заказ- 
чиком, прибмка кода в конце каждой итерации. В методологии ЗСКОМ команда 
является самоорганизующейся и самоуправляемой. Команда берёт на себя обяза- 
тельства по выполнению работ на спринт перед рго4исЁ о\упег. Работа команды 
оценивается как работа единой группы. В ЗСВУОМ вклад отдельных членов команды 
не оценивается, так как это разрушает самоорганизацию команды. Размер команды 
варьируется от 5 до 9 человек. ЗСКОМ использует следующие виды проектных 
документов: ргодисй БасК1о>, зрипё БасК1о>. Ргодис{ БасК]ох — это список имеющихся 
на данный момент требований к разрабатываемой системе с расставленными 
приоритетами. Зрипё БасК]о> содержит функциональность, выбранную рго4ис( о\упег 
из ргодисе БасК1о2. Все функции разбиваются по задачам, каждая из которых оцени- 
вается командой и переносится на итерации. Результатом спринта является готовый 
продукт, который можно передавать заказчику. Длительность спринта - 30 дней, это 
позволяет обеспечивать быструю обратную связь от заказчика к команде [1]. 

Помимо методологии ЗСКОМ была рассмотрена методология экстремального 
программирования. Главный акцент в этой методологии ставится на разработку кода 
как главное занятие программистов. Экстремальное программирование требует 
постоянного использования следующих методик: пересмотр кода (программирование 
парами), автоматическое тестирование кода (тестирование модулей и функциональное 
тестирование), рефакторинг, простота проектных решений, коллективное владение 
кодом, автоматическая сборка и интеграционное тестирование, короткие итерации [2]. 
Полный цикл разработки кода в рамках экстремального программирования состоит из: 
парного решения задачи, разработки кода на основе предварительно разработанных 
тестов, достижения работы тестовых случаев, интеграции только что написанного 
кода в систему и интеграционное тестирование. К сожалению, отдельные из вышепе- 
речисленных методик не могут быть применены в условиях удалённой разработки, 
поэтому полноценное использование методологии экстремального программиро- 
вания для данного проекта было невозможно. 

Следование принципам, пропагандируемым этими методиками, позволяет 
создать баланс между формальными методами и свободой разработки. Однако 
наиболее эффективно они работают при использовании соответствующих инстру- 
ментов разработки: системы контроля версий, системы отслеживания изменений в 
проекте, системы управления заданиями и регистрации ошибок, базы знаний проекта, 
системы сборки. Использование таких инструментов упрощает процесс разработки и 
позволяет автоматизировать рутинные операции. Следует отметить, что использова- 
ние большинства из вышеперечисленных инструментов требует наличия сервера 
проекта, на котором они бы могли быть установлены. Если проект предполагает 
открытую разработку, можно воспользоваться услугами Зоигсе Еогое, который бесп- 
латно предоставляет системы \!П, Зибуегуоп и Тгас. Однако если открытая 
разработка невозможна либо требуется использование каких-либо дополнительных 
сервисов, единственным решением является установка сервера, находящегося в 
режиме оп-Ппе и доступного из сети Пщегеь что и было сделано для данного 
проекта. 
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Распределённая разработка программных проектов предполагает коллективное 
владение кодом. Это означает следующее: любой разработчик может вносить 
изменения в любой участок кода. Это требует разработки и использования единых 
стандартов кодирования. В зависимости от квалификации команды и выбранной 
культуры разработки стандарты могут включать следующие разделы: архитектурные 
требования, требования к физической организации проекта, требования к проектиро- 
ванию, требования к написанию кода на определённом языке (например, С++), 
требования к форматированию кода (как правило, должны быть очень лояльными), 
конвенции именования. Для контроля соответствия кода стандартам следует 
прибегать к ревизиям кода. Более продуктивными являются формальные инспекции 
кода, при которых код анализируется группой разработчиков, каждый из которых 
выполняет свою определённую роль [3]. 

Для снижения рисков и уточнения требований к проекту эффективным 
является применение на ранних этапах разработки построения прототипов решений. 
Проблемы принятия решений по поводу работы системы в целом, как правило, 
связаны с нехваткой информации о тех или иных её аспектах. Однако сбор такой 
информации невозможен без разработки системы, что приводит к появлению замк- 
нутого круга. Выходом из такой ситуации является прототипирование отдельных 
компонентов и реализация частей системы «на выброс» [4], [5]. Кроме того, прототи- 
пы помогают новым разработчикам понять причины принятия решений, поскольку 
моделируют лишь часть функциональности разрабатываемой системы и позволяют 
рассмотреть её отдельные аспекты. 

Для разрабатываемой системы в качестве базовой была выбрана методика 
ЗСКИМ. Для автоматизации процесса использованы следующие инструменты: 
система контроля версий — Зибуегзот [6], интегрированная \уеБ-система поддержки 
разработки — Едоеха| Тгас [7], система сборки проекта — СМУ Маке [8]. В качестве 
основного языка программирования был выбран язык С++, для которого были 
разработаны требования по написанию кода (стандарты кодирования) [9]. Для под- 
систем с высокой вариативностью начата разработка прототипов. 
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